Planificaci´on
Fco. Javier Boh´orquez Ogalla
1
´
Indice
1. Visi´on general 4
2. Metodolog´ıa de desarrollo 4
3. Planificaci´on 5
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Expresiones l´ogicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Sentencias de entrada/salida . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Sistema de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Expresiones aritm´eticas . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. S´ımbolos variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.7. Sentencias de control I . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.8. Interfaz de usuario I . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.9. Expresiones cadenas de caracteres . . . . . . . . . . . . . . . . . . . 14
3.10. Conversi´on de tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.11. Funciones de cadenas . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.12. Expresiones array . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.13. S´ımbolos funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.14. Expresiones regulares . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.15. S´ımbolos clases I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.16. Expresiones condicionales . . . . . . . . . . . . . . . . . . . . . . . 21
3.17. Funciones de depuraci´on . . . . . . . . . . . . . . . . . . . . . . . . 22
3.18. Optimizaci´on de memoria . . . . . . . . . . . . . . . . . . . . . . . 23
3.19. Sentencias de control II . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.20. Paso de argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.21. Interfaz de usuario II . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.22. Procesos I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.23. Fechas y tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.24. Ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.25. Extensiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.26. Extensi´on gettext . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.27. Procesos II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.28. S´ımbolos clases II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.29. S´ımbolos funciones II . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.30. Extensi´on mysql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4. Organizaci´on 35
5. Costes 36
6. Riesgos 37
6.1. Riesgos tecnol´ogicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2. Riesgos personales . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3. Riesgos organizativos . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4. Riesgos de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.5. Riesgos de soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.6. Riesgos de costes, tiempos y recursos . . . . . . . . . . . . . . . . . 43
7. Aseguramiento de calidad 44
1. Visi´on general
En esta secci´on se trata todos los aspectos relativos a la gesti´on del proyecto.
Esta pretende dar alcance a la meta del proyecto y los objetivos del mismo dentro
de las limitaciones dadas: alcance, tiempo, calidad y presupuesto.
La gesti´on del proyecto comprende la implantaci´on de una metodolog´ıa de
desarrollo, vi´endose esta como la implantaci´on de una serie de pasos, t´ecnicas,
procedimientos y dem´as recursos que ayuden a desarrollar el producto software
dentro de un marco de trabajo.
Por otro lado tambi´en se ha de tratar la planificaci´on del proyecto, quedando
este organizado en una serie de tareas y actividades derivadas de la metodolog´ıa
implantada.
En la ejecuci´on de un proyecto es necesario la inversi´on de una serie de recursos,
tales como herramientas, personal, equipos, herraminetas... Se ha de determinar
los recursos asignados a la ejecuci´on del mismo, as´ı como los roles de las personas
asignadas y la relaci´on entre estas.
El desarrollo de un proyecto software tiene unos costes derivados de los recur-
sos asociados al mismo. Estos recursos ser´an tanto materiales como humanos, y
tendr´an un coste fijo asociado que se utilizar´a para el c´alculo del coste total.
Otra de las tareas que se llevan a cabo durante la gesti´on de un proyecto softwa-
re es el an´alisis de riesgos. Todo proyecto esta sujeto a una probabilidad de que se
den escenarios de riesgo en los que se pueda ver perjudicada la correcta realizaci´on
del mismo. Se detectar´an, listar´an y analizar´an los riesgos y sus consecuencias, as´ı
como la probabilidad de que estos sucedan y las pr´acticas que se llevar´an a cabo
para mitigar los efectos derivados de estos.
Por ´utltimo se expondr´an las pr´acticas seguidas para asegurar la calidad del
desarrollo y los productos obtenidos en cada paso de la metodolog´ıa. Para ello se
incuyen est´andares seguidos los est´andares, pr´acticas y normas aplicables durante
el desarrollo. Adem´as se recogen los distintos tipos de revisiones,verificaciones y
validaciones que se han llevado a cabo, as´ı como los criterios para la aceptaci´on o
rechazo de cada producto y los procedimientos para implantar acciones correctoras
o preventivas.
La planificaci´on expuesta no recoje aspectos como la instalaci´on, el manteni-
miento o el soporte. Esta se centra ´unicamente en el ciclo de desarrollo del proyecto
y no en los procesos posteriores, los cuales, aunque tambi´en forman parte del ciclo
de vida h´abil del software, no se encuentran dentro de las etapas de desarrollo del
mismo.
2. Metodolog´ıa de desarrollo
Para la realizaci´on del proyecto se ha seguido una metodolog´ıa iterativa e in-
cremental. M´as concretamente se ha tomado como base el proceso unificado de
desarrollo de software, el cual sigue un enfoque diriguido por casos de uso y cen-
trado en la arquitectura.
El ciclo de vida sigue un enfoque en espiral, dividido en cuatro etapas: deter-
minar objetivos, an´alisis de riesgos, desarrollo y planificaci´on.
Determinar objetivos :
Se fijan los productos a obtener: requisitos, especificaci´on, manuales ...
Se fijan las restrinciones a las que estar´a sujeta el proyecto
S´olo en la primera iteraci´on se lleva a cabo una planificaci´on inicial en
esta etapa.
An´alisis de riesgos :
Se estudia las posibles amenazas y eventos no deseados, as´ı como los
da˜nos y consecuencias derivados de estos.
Se evaluan las distintas alternativas que permitan minimizar los riesgos.
Desarrollo :
Se lleva a cabo el desarrollo de lo fijado en las etapas anteriores.
El desarrollo de cada iteraci´on se divide en cuatro etapas: analisis, di-
se˜no, codificaci´on y pruebas.
Planificaci´on :
Se analiza los productos obtenidos y el estado del proyecto.
Se lleva a cabo una planificaci´on de la siguiente iteraci´on del ciclo de
vida.
En un enfoque en espiral lo m´as com´un es que en la primera iteraci´on se ofrezca
un proptotipo del producto a desarrollar, no obstante en el proyecto abordado no
ha sido as´ı. En lugar de ello se ha planteado una primera iteraci´on que recoja
el alcance del proyecto, as´ı como los requisitos y an´alisis de los riesgos globales,
adem´as se realiza una planificaci´on de las iteraciones que seguir´an. Las dem´as
iteraciones contemplan un subconjunto de estos requisitos a˜nandi´endose as´ı en
cada iteraci´on caracter´ısticas al software y afinando el an´alisis global llevado en la
primera y siguientes iteraciones.
Para la realizaci´on de los productos obtenidos en cada paso de la metodolog´ıa
se a utilizado el lenguaje de modelado UML.
3. Planificaci´on
La planificaci´on se divide en una serie de iteraciones. Todas las iteraciones con
excepci´on de la primera tienen las mismas etapas en funci´on de la metodolog´ıa
seguida.
Las etapas y subetapas en las que se divide cada iteraci´on son:
Objetivos
Riesgos
Desarrollo
• An´alisis
• Dise˜no
• Codificaci´on
• Pruebas
Planificaci´on
La planificaci´on tiene como punto de partida el d´ıa 03/11/2014, d´ıa en la que se
comenz´o el desarrollo del proyecto. Se ha tomado una jornada laboral de 8 horas,
y una semana h´abil de 5 d´ıas.
En cada etapa de la planificaci´on se hacen labores de documentaci´on para que
toda la informaci´on relativa al proyecto quede reflejada en la memoria del mismo.
La primera etapa refleja un planteamiento general del proyecto, este se ha ido
refinando con cada iteraci´on del ciclo de vida. Para ello se han modificado los
documentos obtenidos de iteraciones anteriores.
3.1. General
Figura 1: General: 03/11/2014 - 05/11/2014
3.2. Expresiones l´ogicas
Figura 2: Exp. l´ogicas: 06/11/2014 - 12/11/2014
3.3. Sentencias de entrada/salida
Figura 3: Sentencias I/O: 13/11/2014 - 18/11/2014
3.4. Sistema de errores
Figura 4: Sistema de errores: 19/11/2014 - 21/11/2014
3.5. Expresiones aritm´eticas
Figura 5: Exp. aritm´eticas: 24/11/2014 - 28/11/2014
3.6. S´ımbolos variables
Figura 6: S´ımbolos variables: 01/12/2014 - 14/12/2014
3.7. Sentencias de control I
Figura 7: Sentencias control I: 15/12/2014 - 19/12/2014
3.8. Interfaz de usuario I
Figura 8: Interfaz usuario I: 07/01/2015 - 13/01/2015
3.9. Expresiones cadenas de caracteres
Figura 9: Interfaz usuario I: 14/01/2015 - 20/01/2015
3.10. Conversi´on de tipos
Figura 10: Conversi´on de tipos: 21/01/2015 - 23/01/2015
3.11. Funciones de cadenas
Figura 11: Funciones de cadenas: 26/01/2015 - 29/01/2015
3.12. Expresiones array
Figura 12: Expresiones array: 30/01/2015 - 12/02/2015
3.13. S´ımbolos funciones
Figura 13: S´ımbolos funciones: 13/02/2015 - 26/02/2015
3.14. Expresiones regulares
Figura 14: Expresiones regulares: 27/02/2015 - 05/03/2015
3.15. S´ımbolos clases I
Figura 15: S´ımbolos clases I: 06/03/2015 - 12/03/2015
3.16. Expresiones condicionales
Figura 16: Expresiones condicionales: 13/03/2015 - 17/03/2015
3.17. Funciones de depuraci´on
Figura 17: F´unciones de depuraci´on: 18/03/2015 - 20/03/2015
3.18. Optimizaci´on de memoria
Figura 18: Optimizaci´on de memoria: 23/03/2015 - 27/03/2015
3.19. Sentencias de control II
Figura 19: Optimizaci´on de memoria: 23/03/2015 - 27/03/2015
3.20. Paso de argumentos
Figura 20: Paso de argumentos: 06/04/2015 - 08/04/2015
3.21. Interfaz de usuario II
Figura 21: Interfaz de usuario II: 09/04/2015 - 15/04/2015
3.22. Procesos I
Figura 22: Procesos I: 16/04/2015 - 21/04/2015
3.23. Fechas y tiempo
Figura 23: Fechas y tiempo: 22/04/2015 - 24/04/2015
3.24. Ficheros
Figura 24: Ficheros: 27/04/2015 - 29/04/2015
3.25. Extensiones
Figura 25: Extensiones: 30/04/2015 - 06/05/2015
3.26. Extensi´on gettext
Figura 26: Extensiones gettext: 07/05/2015 - 08/05/2015
3.27. Procesos II
Figura 27: Procesos II: 11/05/2015 - 12/05/2015
3.28. S´ımbolos clases II
Figura 28: S´ımbolos clases II: 13/05/2015 - 19/05/2015
3.29. S´ımbolos funciones II
Figura 29: S´ımbolos funciones II: 20/05/2015 - 26/05/2015
3.30. Extensi´on mysql
Figura 30: Extensi´on mysql: 27/05/2015 - 29/05/2015
4. Organizaci´on
Para la realizaci´on del proyecto se ha utilizado los siguientes recursos humanos
:
Empleado 1: Director de proyecto, control de calidad.
Empleado 2: Analista, dise˜nador de arquitectura, dise˜nador de sistemas, desa-
rrollador, tester.
Adem´as se han utilizado los siguientes recursos materiles:
Equipo de trabajo 1: Computadora para las tareas de gesti´on y administraci´on.
Equipo de trabajo 2: Computadora para las tareas de desarrollo y documenta-
ci´on
Las herraminetas utilizas son las siguientes:
Sistema operativo: GNU/Linux.
Entorno integrado de desarrollo: Geany.
Generador l´exico: Flex.
Generador sint´actico: Bison.
Compilador: GCC.
Depurador: GDB.
Herramientas para la construcci´on autom´atica: Autoconf, automake, ma-
ke.
Desarrollo de diagramas: Dia, railroad diagram generator.
Control de versiones: Subversion.
Creaci´on de documentaci´on: Latex.
Planificaci´on: Planner.
Bibliotecas de desarrollo: readline, boost.
Comunicaci´on: Servicio gratuito de correo electr´onico.
5. Costes
A continuaci´on se presenta el coste relativo a los recursos humanos invertidos
en el desarrollo del proyecto. Para ello se ha tomado como referencia el documento
BOE publicado el s´abado 30 de nobiembre de 2013 por el ministerio de empleo y
seguridad social. En este documento se recoje la tabla salarial seg´un el convenio
colectivo de la empresa Trevenque Sistemas de Informaci´on SL.
Empleado Grupo Salario anual bruto Salario mensual bruto
Empleado 1 Directivo t´ecnico 26.652,92€ 2.221,07€
Empleado 2 Programado senior 18.120,00€ 1.510,00€
El tiempo de desarrollo asciende a 8 meses. El coste de los recursos humanos
es:
Empleado 1 17.768,56€
Empleado 2 12.080,00€
Total 29.848,56€
Para el desarrollo del proyecto se ha necesitado de dos equipos con una poten-
cia y prestaciones medias. El coste de los recursos materiales que suponen estas
computadores es:
Computador i5-4460/ 4GB/ 1TB 2x 409,00€
Total 818,00€
Las herramientas utilizadas en el desarrollo del proyecto tiene licencia libre.
El uso de estas herramientas no suponen coste adicional para el desarrollo del
proyecto.
6. Riesgos
En este punto se muestran listan los riesgos identificados. Estos pueden originar
un efecto negativo en el desarrollo del proyecto. Adem´as se muestra la probabilidad
de que estos se den y el impacto que tendr´ıan. Una vez identificados los riesgos se
definen los planes seguidos para reducir los efectos derivados estos o disminuir la
probabilidad de que ocurran.
El an´alisis de riesgos se ha llevado a cabo en cada iteraci´on del ciclo de desarro-
llo. Cada iteraci´on a completado la informaci´on mostrada. Muchos de los riesgos
indicados son comunes a todas las iteraciones realizadas.
Los riesgos analizados seg´un el impacto que pueden ocasionar en el proyecto
quedan divididos en:
Insignificantes: No merecen ser tenido en cuenta.
Tolerables: Est´an dentro de un marge de aceptaci´on, por tanto no compromenten
ni el proyecto, ni el producto ni la organizaci´on.
Graves: Compromente gravemente el proyecto, el producto o la organizaci´on.
Cr´ıticos: Amenaza la supervivencia del proyecto o el producto o la organizaci´on.
Para dar claridad al an´alisis, la probabilidad de que se d´e un determinado
escenario de riesgo se presenta de forma relativa de la siguiente forma:
Muy baja: < 10 %.
Baja: del 10 al 25 %.
Moderada: del 25 al 50 %.
Alta: del 50 al 75 %.
Muy alta: > 75 %.
Los riesgos quedan organizados en distintas categor´ıas para un mejor an´alisis.
6.1. Riesgos tecnol´ogicos
Son los riesgos derivados del software y hardware necesarios para el desarrollo
del proyecto.
Riesgo Probabilidad Impacto
Los recursos no est´an disponibles a tiempo Baja Tolerable
Fallos en el sistema operativo
u otros software de sistema Baja Tolerable
Fallos en el hardware de desarrollo Baja Grave
Errores de configuraci´on Baja Tolerable
Actualizaci´on del sistema
no realizada correctamente Baja Tolerable
Integridad y privacidad de los datos Baja Grave
Manipulaci´on deliberada de los programa Moderada Grave
Las herramientas de comunicaci´on
no se encuentran disponibles Baja Insignificante
El repositorio de c´odigo no se encuentra
disponible Baja Tolerable
En el caso de que los recursos materiales, hardware de desarrollo, no est´en
disponibles a tiempo se puede comenzar con tareas de definici´on y an´alisis. Si
la demora se hace demasiado extensa se cancelar´a el pedido del hardware y se
realizar´a a otro proveedor. Esto puede ocasionar un retraso de d´ıas que puede ser
mitigado dedicando este tiempo a tareas en las que no se precise de hardware.
Si se produce alg´un fallo en el software de sistema que da soporte al desarrollo
este puede derivar en p´erdidas de datos. La soluci´on ser´ıa gestionar la incidencia
o reinstalar el sistema. La perdida de datos se puede mitigar si se realizan copias
de seguridad peri´odicas. Como medida preventiva se pueden guardar puntos de
restauraci´on del sistema para preveenir o mitigar la demora de tiempo que esto
podr´ıa ocasionar.
Es posible que se produzcan fallos en el hardware sobre el cual se desarrolla
el proyecto, esto puede ocasionar retrasos de entregas o la perdida de los datos.
Para prevenir y mitigar este efecto negativo se puede realizar copias peri´odicas
de los datos y mantener los equipos en un estado de funcionamiento ´optimo, bien
refigerados y sin exposici´on a agentes externos.
Si se produce alg´un error en la configuraci´on del sistema es posible que algunas
caracter´ısticas de este dejen de funcionar, en muchos casos esto puede llegar a ser
perjudicial para el proyecto. Para prevenir y mitigar este efecto se deber´an realizar
copias de seguridad, adem´as se deber´a minizar la cantidad de software instalado
en los equipos. En el caso de producirse un fallo de configuraci´on del sistema que
afecte directamente a la ejecuci´on del proyecto se deber´a invertir tiempo para
corregir las causas y administrar el sistema.
En algunos casos una actualizaci´on del sistema que da soporte a la ejecuci´on
del proyecto puede ocasionar fallos en el mismo o en la configuraci´on. Para ello
adem´as de las soluciones y practicas comentadas en los puntos anteriores, se puede
minimizar el n´umero de actualizaciones que no sean cr´ıticas o que no sean indes-
pensables para el desarrollo del proyecto. Como medida de actuaci´on el sistema
deber´a ser restablecido mediante un administrador cualificado.
La integridad y privacidad de los datos se puede ver comprometida por alg´un
uso indebido de los mismos o por agentes ajenos al proyecto. Para prevenir y
mitigar los efectos de este escenario se realizar´an copias de seguridad peri´odicas y
se har´a uso de un software de control de versiones. Adem´as se proteger´a el acceso
a los datos mediante t´ecnicas como claves de acceso, configuraciones de red pocos
permisivas (por ejemplo mediante el uso de firewalls), configuraciones ´optimas del
sistema (en cuanto servicios y programas), cifrado, no permitir la conexi´on de
dispositivos extraibles, etc. Es muy importante en este punto controlar adem´as
los permisos de publicaci´on, transferencia y portabilidad que tienen los empleados
sobre los datos, quedando registrada y validada toda operaci´on de esta naturaleza.
Como medida de actuaci´on ante un escenario de este tipo los datos quedar´an
en cuarentena y se llevar´a a acabo un an´alisis forense que determine los agentes
implicados y los motivos.
Es posible que en algunos casos los programas que conforman el sistema sobre
el que se desarrolla sean manipulado de forma consicinete o inconsiente por una
persona integrante del equipo o ajena al mismo. Para prevenir este escenario se
acotar´a el uso del equipo al prop´osito que este tiene, no se permitir´a la instalaci´on
de software adicional, se proteger´a el acceso al sistema mediante claves robustas y
se usar´a software antivirus. Como medida de actuaci´on se bloquear´a el acceso al
proyecto a cualquier software que se tenga constancia de que se encuentre mani-
pulado o infectado por alguna clase del malware, y el equipo implicado se podr´a
en cuarentena para evaluar el impacto de lo ocurrido.
Las herramientas de comunicaci´on son un elemento clave en el desarrollo de
un proyecto. Depender de terceros para dar soporte al proyecto en este aspecto
puede llegar a ser perjudicial. Para prevenir p´erdidas en el servicio se puede usar
clientes estables, fiables y consolidados en el mercado. Para mitigar la perdida de
informaci´on que supondr´ıa una ca´ıda del servicio se puede hacer copias de toda la
informaci´on enviada por estos medios. Como medida de actuaci´on, simpre y cuando
sea necesario una comunicaci´on, se utilizar´an otros medios de comunicaci´on como
el tel´efono.
El repositorio en el cual se aloja el c´odigo fuente puede sufrir ca´ıdas en el
servicio. Para mitigar y prevenir este tipo de incidencias se alojar´a el sistema de
control de versiones en alguna m´aquina de la infraestructura local al proyecto.
Esto bloquea o dificulta el acceso remoto al c´odigo, lo cual tiene sus ventajas
ya que disminuye el grado de exposici´on, pero hace que el acceso al c´odigo est´e
condicionado por un equipo local, y por la disponibilidad y visibilidad de este.
6.2. Riesgos personales
En esta secci´on quedan registrados los riesgos asociados a las personas involu-
cradas en el proyecto.
Riesgo Probabilidad Impacto
Cambios en el personal directivo Baja Cr´ıtico
Cambios en el personal ejecutivo Baja Grave
Los cambios en el equipo directivo de un proyecto pueden amenazar dr´asti-
camente la supervivencia y desarrollo de este. El nuevo personal no tiene porque
compartir los mismos criterios que el anterior, y lo normal es que no conozca as-
pectos internos del mismo. Un cambio directivo en el proyecto puede ocasionar
remplanteamientos de cuestiones que ya se encontraban cerradas. Este tipo de
riesgos es dif´ıcil de preveenir por otros medios que no sean contratos laborales, y
a´un as´ı no se podr´ıa asegurar que el equipo se mantendr´a. Para mitigar el efecto
que un cambio de este tipo podr´ıa ocasionar toda decisi´on directiva deber´a quedar
analizada, argumentada y registrada.
El personal ejecutivo es escencial para el desarrollo de un proyecto, por lo que un
cambio de este tipo en el equipo puede suponer un alto riesgo para el desarrollo. Al
igual que en el punto anterior los contratos laborales puden prevenir en cierto grado
el riesgo. Para mitigar el efecto se deber´a documentar todo los procesos y productos
obtenidos. Como medida de actuaci´on, siempre que sea posible, el anterior personal
podr´ıa instruir al nuevo hasta que tome la destreza y conocimientos suficientes.
6.3. Riesgos organizativos
En esta secci´on se presentan y analizan los riesgos relativos a la organizaci´on
del proyecto.
Riesgo Probabilidad Impacto
Las tareas no quedan bien definidas y/o acotadas Moderada Tolerable
Las tareas no quedan bien distribuidas Moderada Tolerable
No se atribuyen responsabilidades Baja Tolerable
No se establece una jerarqu´ıa de prioridades Baja Tolerable
La comunciaci´on entre el equipo no es suficente Moderada Tolerable
Si las tareas no quedan bien definidas y acotadas se originar´a fallos en la comu-
nicaci´on y el entendimiento entre los integrantes del equipo, pudiendo en muchos
casos originar trabajo extra y la consecuente dilataci´on en los tiempos. Para pre-
veenir y mitigar este efecto se deber´a realizar una descripci´on minusiosa y detallada
de las mismas, utilizando un lenguaje sencillo y directo. El plan de actuaci´on ante
estas situaciones ser´a la aclaraci´on de los puntos que fueron confusos, mientras que
la parte que no lleg´o a enteder las cuestiones planteadas no deber´a presoponer y
pidir´a la aclaraci´on pertinente.
Si las tareas no se encuentran bien distribuidas puede darse esceso de trabajo
por algunas de las partes, ocasionando efectos de parada en el proceso de desarrollo.
Por otro lado otros recursos pueden quedar ociosos. Para evitar y mitigar este
escenario se deber´a analizar y planificar todo el trabajo a realizar. En el caso
de que una planificaci´on incorrecta derive en problemas de este tipo se deber´a
replantear el trabajo.
Un equipo en el que las responsabilidades no queden bien atribuidas puede ori-
ginar en la falta de implicaci´on y correci´on por alguna de las partes. Para prevenir
y mitigar este efecto se deber´a hacer una correcta planificaci´on, incolucrando al
personal y hacerles entender la imporancia de su trabajo.
Si no se establece una jerarqu´ıa de prioridades en las tareas puede ocasionar
la perdida de tiempo en tareas menos importantes, mientras que otras m´as prio-
ritarias y de las que existan dependencias quedar´an paradas. Para evitar esto se
deber´a realziar una planificaci´on y hacer entender a todo el equipo las prioridades
marcadas. Bajo esta circustancias se deber´a retribuir prioridades y hacer que todo
el equipo sea consciente de estas.
Si no se mantiene una comunicaci´on suficiente el proyecto puede verse perjudi-
cado en su ejecuci´on. El equipo directivo puede no conocer el estado verdadero del
proyecto y las decisiones tomadas no contar con toda la informaci´on posible. Para
mitigar y prevenir este escenario se pueden realizar reuniones constantes. Como
medida de actuaci´on ante esta situaci´on se deber´a comunicar a los implicados la
importancia de la informaci´on que poseen.
6.4. Riesgos de requisitos
Son riesgos que surgen de los requisitos, ya sean debido a que estos han cam-
biado o que no se han recojido correctamente.
Riesgo Probabilidad Impacto
Especificaci´on de requisitos insuficiente Moderada Grave
Captura de requisitos err´onea Moderada Grave
Casos de uso complejos o mal redactados Baja Tolerable
No se han capturado todos los datos
que definen o con los que trabaja el sistema Baja Tolerable
A˜nadir nuevas caracter´ısticas sin tener en
cuenta la arquitectura interna del sistema Alta Tolerable
Si los requisitos no son enumerados y definidos de forma efectiva puede ocasio-
nar un sistema que no hace lo que debe hacer. Para evitar esto se llever´a a cabo
m´ultiples reuniones con el cliente para la toma de requisitos, donde el analista
tomar´a parte activa de estas y nunca llegar´a a presuponer ning´un aspecto que
no quede bien acotado. En este punto el analista podr´a optar por algunas de las
t´ecnicas conocidas para la toma de requisitos. Como plan de actuaci´on se deber´a
poner en conctacto con el cliente y pedir la aclarac´on o especificaci´on de los puntos
que no quedaron fijados.
De igual forma unos requisitos mal tomados puede tener como resultado un
producto que no cumple con las espectativas. Para prevenir y evitar este escenario
el analista debe ser muy conciso y minusioso en la toma de requisitos, haciendo
que todo quede claro por ambas partes.
Aunque se realice una toma de requisitos completa, queda la posibilidad que
el analista no transmita correctamente qu´e va a hacer el sistema para dar soluci´on
a estos. Se deber´a poner especial antenci´on en que los casos de usos queden bien
redactados, en un lenguaje simple y con la suficiente sencillez y completud.
Una de las principales actividades de un sistema informaticos es procesar datos,
dado que el valor de la informaci´on viene atribuido por los datos que la forman.
Si los datos sobre los que opera o definen el sistema no son determinados con
exactitud el valor que este aporta disminuye. En la toma de requisitos se ha de
poner especial atenci´on en recojer los datos que construyen el modelo de datos de
una forma completa y exacta.
Definir nuevos requisitos del sitemas conociendo la estructura y caracter´ısticas
internas de este es una ventaja, no obstante no siempre es posible hacer que los
nuevos requisitos se adapten a las posibilidades que el software brinda, ni el cliente
tiene porque conocer las restrinciones que determinadas decisiones de dise˜no han
impuesto. Para prevenir y mitigar este efecto, y que el software sea ampliable en
caracter´ısticas de una forma abierta, se deben dise˜nar soluciones vers´atiles, flexibles
al cambio y con las minimas restricciones asociadas.
6.5. Riesgos de soluciones
Son riesgos asociados con el dise˜no de soluciones
Riesgo Probabilidad Impacto
Dise˜no de soluci´on err´onea o demasiada restrictiva Moderada Grave
Cambios versiones y caracter´ısticas
de las soluciones software utilizadas Baja Tolerable
No se encuentra un l´exico adecuado Baja Tolerabla
La gram´atica es confusa Moderada Tolerable
No se ha seguido el principio de
reutilizaci´on de c´odigo Baja Tolerable
C´odigo inteligible Baja Tolerable
Errores de seguridad Moderada Grave
El tomar como base una soluci´on err´onea puede ocasionar que el software no
produzca los resultados esperados. Si los errores son detectado a tiempo el impacto
puede ser bajo, pero si el error persiste en varias iteraciones del proceso de desa-
rrollo puede ocasionar p´erdidas cuantiosas. Para prevenir esta situaci´on se deben
pasar auditor´ıas de calidad en todas las iteraciones, no solo en el sentido de que
la soluci´on se ha aplicado correctamente, sino tambien de que estas cumple unos
criterios m´ınimos de optimizaci´on, seguridad, flexibilidad, etc. Cuando se detecta
que una soluci´on tomada no es correcta se deber´a analizar el coste de las distintas
alternativas para corregirlo y si fuera necesario aplicar la m´as ´optima para el caso.
Muchas soluciones software utilizadas pueden cambiar de versi´on y con ella
las caracter´ısticas que ofrecen, pudiendo quedar algunas de ellas eliminadas. Esto
puede ocasionar que el sistema desarrollado no cumpla con lo que antes s´ı hac´ıa.
Para evitar esta situaci´on siempre se guardar´a una versi´on estable de las soluciones
software tomadas. Antes de actualizar el software que da soluci´on a alg´un aspecto
del sistema se deber´a tener en cuenta el impacto que esta operaci´on tendr´a. En el
caso de ser necesario actualizar se deber´a apatar el sistema para el uso de la nueva
versi´on.
Para un lenguaje de programaci´on el disponer de un l´exico sencillo, f´acil de
recordad y com´un en otros lenguajes es un requisito necesario, si esto no se logra
el resultado es un lenguaje que el mercado no estar´a dispuesto a usar. Para prevenir
esto se ha de analizar y medir cada palabra que componga el l´exico, someti´endolo a
evaluaci´on por todo el equipo y por personas ajenos al mismo. s posible tomar como
referencias otros lenguajes disponibles en el mercado. Si se detecta o se determina
que una determinada del l´exico no es adecuada se deber´a de cambiar.
De igual forma que en el punto anterior, una gramatica confusa puede originar
un lenguaje poco usado, cuyo coste de aprendizaje sea elevado. Nuevamente para
evitar este escenario se deber´a analizar y evaluar la estructura de la gram´atica
elegida. Si se detecta una gram´atica confusa se deber´a analizar y proponer otras
alternativas.
Una soluci´on desarrollada que no sea reutilizable implica la m´ultipe realizaci´on
del trabajo. Para mitigar y prevenir este efecto se deber´a modularizar y acotar
toda funci´on que se pueda reutilizar. Las funciones, clases y dem´as recursos de
programaci´on deben tener un prop´osito concreto y bien definido. Si se detecta que
una determinada parte del sistema se est´a rescribiendo por no seguir un principio
de reutilizaci´on se deber´a invertir tiempo en invertir esta situaci´on.
Hacer que el sistema se conforme de partes de c´odigo que no sean f´aciles de
entender o seguir puede ir en contra del mantenieminto del proyecto y de la co-
rrecci´on del sistema. Para prevennir este escenario se deber´a seguir unas reglas de
estilo uniforme que construyan un c´odigo limpio y f´acil de entender. Al detectar
este tipo de c´odigo se ha de invertir tiempo en clarificar la secci´on afectada.
Al escribir programas complejos y extensos es muy com´un que se den fallos
de seguridad que permitan explotar vulnerabilidades como podr´ıa ser el desbor-
damiento de buffer o alg´un tipo de inyecci´on. Para evitar esto se podr´a realizar
auditorias de seguridad al c´odigo desarrollado. Si se detecta alg˜n´un fallo de segu-
ridad en la fase de desarrollo este debe ser notificado y corregido.
6.6. Riesgos de costes, tiempos y recursos
En esta secci´on se exponen los riegos derivados de c´alculos en cuanto a costes,
recursos y tiempo.
Riesgo Probabilidad Impacto
N´umero de empleados insuficiente Baja Tolerable
Recursos necesarios no previstos Baja Tolerable
Planificaci´on optimista Moderada Tolerable
La planificaci´on de la siguiente iteraci´on
tarda m´as de lo esperado Moderada Tolerable
El presupuesto es insuficiente para
afrontar el desarrollo Baja Cr´ıtica
Si el n´umero de empleados contratados para el proyecto es insuficiente el tiempo
necesario para el desarrollo del mismo puede incrementar considerablemente. Por
otro lado contratar empleados conlleva un coste monetario. Es por tanto que se
debe llegar a una configuraci´on ´optima. Para prevenir este escenario se ha de
llevar a cabo una planificaci´on realista llevada a cabo desde la experencia y de una
forma objetiva. Si la realidad difiere de la planificaci´on realizada y se precisa de
m´as empleados, habr´a que asumir el coste de contrataci´on adem´as del tiempo de
incorporaci´on que varir´a en funci´on del perfil.
Es posible que en la planificaci´on inicial no se contemple la totalidad de los re-
cursos materiales necesarios. Esto podr´ıa originar retrasos en las entregas y tiempos
de espera. Para mitigar este efecto se puede tener un fondo reservado para posi-
bles gastos adicionales no previsto, no obstante lo ideal es hacer una planificaci´on
exacta en cuanto a los recursos requeridos.
Es com´un que muchas planificaciones se hagan desde un punto de vista opti-
mista, esto conlleva desviaciones entre el tiempo calculado, los recusos invertidos
y los compromisos llegados con lo que se materialice en la realidad. Para evitar
este escenrio, se deber´a llevar a cabo una planificaci´on realista, con m´argenes de
actuaci´on.
Retardar la planificaci´on de la siguiente iteraci´on puede llegar a ser un problema
que bloquee el proceso de desarrollo, dado que no se han amrcados las pautas para
continuar. Para mitigar esto la planificaci´on puede desarrollarse de forma pararela
al recorrido de la iteraci´on actual.
Es posible que el presupuesto para la realizaci´on del proyecto quede insuficiente,
esto puede ocasionar el cese de la actividad del mismo. Como m´etodo de previsi´on
se puden estudiar varias alternativas de financiaci´on.
7. Aseguramiento de calidad
Para asegurar una calidad aceptable del producto y los procesos llevados a cabo
en el desarrollo se ha tomado como esquema el conjunto de normas ISO 9000. El
sistema de gesti´on de la calidad est´a formado por procesos y es en si mismo un
proceso en el que ingresan los requisitos del sitema y se obtiene un producto que
cumple los requisitos y satisface al cliente.
A continuaci´on se describen los procesos y actividades seguidas para asegurar
la calidad.
Se implementa un ciclo de vida evolutivo en el que se examina y documenta
cada decisi´on tomada, al final de cada iteraci´on se comprueba la calidad del
producto obtenido.
El equipo directivo se asegura de que los requisitos del cliente se determinan
y cumplen. El objetivo de esto es aumentar la satisfaci´on del mismo.
El equipo directivo realiza una planificaci´on en la que se capturen las acciones
a seguir para alcanzar los objetivos perseguidos.
Los roles y responsabilides del equipo quedan definido y atribuidos en cada
iteraci´on del ciclo.
En cada iteraci´on se examina las pruebas de calidad realizadas, la retroali-
mentaci´on del cliente y la conformidad del producto.
En cada iteraci´on se contemplan las mejoras del producto en relaci´on con los
requisitos y necesidades del cliente.
Todo el personal tiene los conocimientos y el entrenamiento adecuados para
realizar la tarea que en la planificaci´on se le ha sido asignada.
Se utilizan entrevistas peri´odicas con el cliente para captur´a los requisos
necesarios en cada iteraci´on. Adem´as de validar la correcci´on del producto
obtenido
Para la toma de requisitos se ha utilizado t´ecnicas de objetivos medibles, de
forma que los requisitos impuesto por el cliente se ven como objetivos gene-
rales. Estos son analizados repetidamente para obtener los requisos cr´ıticos
para el funcionamineto del sistema. En cada iteraci´on se refinan los requisitos
generales y se plantean nuevos, aplic´andose la misma t´ecnica para determiar
los tomados en la iteraci´on.
Se presentan modelos de caso de uso que deben ser comprendidos y validados
por el cliente.
El dise˜no del producto obtenido en cada iteraci´on queda documentado me-
diante modelos.
Se realiza una revisi´on, verificaci´on y validaci´on de los dise˜nos propuestos.
La actividad de desarrollo del producto quedar´a bien documentada en el
propio c´odigo.
En cada iteraci´on se definir´an los casos de pruebas, estas ser´an llevadas a
cabo para comprobar la correcci´on del producto.
A continuaci´on los criterios para la aceptaci´on o rechazo de los productos ob-
tenidos en cada fase del desarrollo.
Si se detecta alg´un requisito ambiguo o mal especificado este queda rechaza-
do. En este caso se deber´a concertar una entrevista con el cliente.
Para la aceptaci´on de los requisitos estos deben ser simples y sencillos, estar
bien descritos y especificados de forma at´omica.
Si se detecta un caso de uso mal explicado o confuso este ser´a rechazado.
Los casos de uso para su aceptaci´on deben estar completamente explicados,
de una forma esquem´atica y f´acil de entender por el cliente. Adem´as debe
quedar bien definidos los actores involucrados y las relaciones entre estos.
Los modelos de datos ser´an aceptados si son claros, completos y se encuentran
bien estructurados.
Los dise˜nos de soluciones ser´an aceptados si cumple los criterios de versati-
lidad, adaptaci´on, optimizaci´on y claridad impuestos.
Si en el dise˜no de la gram´atica se da alguna ambiguedad esta deber´a ser
redefinida.
Si la elecci´on de una palabra del l´exico es confusa o demasiado compleja esta
deber´a ser redefinida.
Si alguna clase no cumple el principio de ´unica resposabilidad ser´a rechaza.
Si alguna clase no cumple el principio abierto/cerrado ser´a rechaza.
Si alguna clase no cumple el principio de sustituci´on de Liskov ser´a rechaza.
Si alguna clase no cumple el principio de segregaci´on de la interfaz ser´a
rechaza.
Si alguna clase no cumple el principio de inversi´on de dependencias ser´a
rechaza.
Si alg´un m´odulo de c´odigo fuente desarrollado no cumple las reglas de estilo
este ser´a rechazado.
Si alg´un m´odulo de c´odigo fuente no se encuentra debidamente docuemtado
ser´a rechazado.
Si alg´un m´odulo de c´odigo fuente no sigue el principio de reutilizaci´on ser´a
rechazado.
Si se detecta que no se han capturados todos los casos de prueba escenciales
se produce un rechazo.
Para la aceptaci´on se deben completar satisfactoriamente todas las pruebas
unitarias.
